<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Philip Kwok, Andy Ogielski, BJ Premore">
   <title>SSF Implementation of static OSPFv2 v0.1.14</title>
</head>

<body bgcolor="white">

<h2>SSF Implementation of OSPF v0.1.14</h2>

<hr width="100%">
<b><font size="+1"><i>Contents</i></font></b>
<dl>
<dt><a href="#intro">Introduction</a>
<dt><a href="#compliance">Future Work</a>
<dt><a href="#src">Source Code</a>
<dt><a href="#validation">Validation</a>
<dt><a href="#faq">Questions and Help</a>
<dt><a href="#references">References</a>
<dt><a href="#about">Authors</a>
</dl>
<hr width="100%">

<a name="intro"></a>
<h3>Introduction</h3>

<p align="justify">
The Open Shortest Path First (OSPF) protocol is an IP link-state routing
protocol, recommended for distributing routing information among the routers in
a single autonomous system (AS), with explicit support for classless
inter-domain routing (CIDR) address allocation.
</p>

<p align="justify">
SSF.OS.OSPF is a partial implementation of OSPFv2, based on the Internet
Engineering Task Force's Request for Comments number 2328 (RFC 2328), "OSPF
Version 2" <a href="#ref1">[1]</a>.  It is designed to quickly compute the
routing tables for arbitrary topologies of OSPF areas in SSFNet network models,
and to flood the area with external route announcements from the ASBR routers
running the BGP-4 inter-domain routing protocol.  The unsupported requirements
involve dynamic neighbor discovery and link state updates in response to
dynamic topology changes.
</p>

<p align="justify">
This implementation is referred to as sOSPF (static OSPF). See SSF.OS.OSPFv2
for the more complete implementation of OSPFv2 including the dynamic responses
to routing topology changes.
</p>

<p align="justify">
sOSPF is a static version of OSPF which retrieves the adjacency information of
all routers in the same AS directly from the underlying network topology
database.  It then forms the link state databases by retrieving the link
properties, and subsequently invokes the shortest path algorithm to compute the
routing tables.  In this release each router maintains its own link state
database.  This arrangement permits simulations to be run in parallel (with
multiple timelines).  However, since all link state databases within an area
are essentially identical, for the purpose of saving memory in a simulation it
is possible to maintain a single shared link database per area, provided the
updates from routers are carefully synchronized to avoid possible errors in a
multi-timeline simulation.  Such a solution can be provided in a future
release.
</p>

<p align="justify">
In sOSPF version 0.1.14 only one area per AS is supported.  However, sOSPF can
accept dynamic AS external route information from inter-AS routing protocols,
such as BGP. The routing table computed by an sOSPF ProtocolSession contains
the entries for:
</p>

<ul>
<li>all stub networks in the area,
<li>all hosts attached directly to sOSPF routers,
<li>summary networks received from external ASs,
<li>all point-to-point links attached directly to this router
    (enough for flooding the external route announcements),
</ul>
  
<p align="justify">
but it does not contain addresses of point-to-point networks between sOSPF
routers inside the area that are not directly attached to this router.  That
does not affect routing of IP packets between hosts.  See the <a
href="../test/"><code>OSPF/test/</code></a> directory for examples.
</p>

<p align="justify">
An sOSPF ProtocolSession accepts AS external routing information from inter-AS
routing protocols, such as BGP. These other protocols inject routing
information using the method <code>sOSPF.acceptASExternalRoute()</code>. Such
routes are inserted first into the link state database, as stipulated by RFC
2328. Then <code>sOSPF.buildRoutingTable()</code> is called, where Dijkstra's
algorithm is run again on the database, and the router's forwarding table is
updated.
</p>

<p align="justify">
This release has not yet been exercised under a sufficiently broad range of
scenarios, and we would welcome ideas for additional tests to help establish a
canonical test suite for all OSPF implementations.
</p>


<a name="compliance"></a>
<h3>Future Work</h3>


<p align="justify">
<b>1. Link Cost Specification in the network DML database</b><br>

sOSPF permits arbitrary link cost values to be used. However, it does not yet
permit to specify the link costs directly in the network configuration DML
database. This will be provided in the next release.
</p>

<p align="justify">
<b>2. Support for Multiple Areas</b><br>
</p>

<p align="justify">
<b>3.&nbsp;Broadcast,&nbsp;Non-Broadcast&nbsp;Networks,&nbsp;Designated&nbsp;Router&nbsp;and&nbsp;Backup&nbsp;Designated&nbsp;Router</b><br>

OSPF can run on both broadcast and non-broadcast networks.  Version 0.1.14
makes no such distinction.  OSPF can run over non-broadcast networks in NBMA or
Point-to-MultiPoint mode. In NBMA mode, OSPF emulates operation over a
broadcast network: a Designated Router is elected for the NBMA network, and the
Designated Router originates an LSA for the network. NBMA mode is the most
efficient way for non-broadcast networks, but it requires all routers attached
to the NBMA network to be able to communicate directly. In Point-to-MultiPoint
mode, OSPF treats all router-to-router connections over the non-broadcast
network as if they were point-to-point links. No Designated Router is elected
for the network, nor is there an LSA generated for the network. In fact, a
vertex for the Point-to-MultiPoint network does not appear in the graph of the
link-state database.  Refer to RFC 2328 sections 2.1.1, 7.3, and 7.4.
</p>

<p align="justify">
<b>4. IP Multicast</b><br>

IP multicast is not used in version 0.1.14.  Refer to RFC 2328 section 4.4.
</p>

<p align="justify">
<b>5. Neighbor State Machine</b><br>

RFC 2318 goes into great length specifying the neighbor state machine, and the
neighbor states such as HelloReceived, Adjacent, Down. This is not needed in
the static version, but will be required in dynamic version.  Refer to RFC 2328
section 10.3.
</p>

<p align="justify">
<b>6. Representation of Type of Service</b><br>

In the dynamic version the TOS informaton can be included in the router-LSAs,
summary-LSAs and AS-external-LSAs.  However, they are not implemented in sOSPF
version 0.1.14.  Refer to RFC 2328 section 12.3.
</p>


<a name="src">
<h3>Source Code</h3>

<p>
Archived Java source: <a href="http://www.ssfnet.org/ospf/"><code>http://www.ssfnet.org/ospf/</code></a><br>
Modification history: <a href="HISTORY">OSPF/doc/HISTORY</a><br>
</p>

<a name="validation"></a>
<h3>Validation</h3>

In the absence of any pre-existing ones, we have begun to compose a suite of <a
href="validation.html">validation tests for SSF.OS.OSPF</a>.  It includes tests
for checking router classification, router adjacency, correctness of link state
databases, and correctness of routing tables.

<a name="faq">
<h3>Questions and Help</h3>

<p align="justify">
SSFNet uses an interactive FAQ (the SSFNet Faq-O-Matic) which contains several
answers to frequently asked questions about SSFNet and all of its components,
including SSF.OS.OSPF.  Users can also log in and post new questions, which
others in the SSFNet modeling community can respond to by posting their own
answers.  The SSFNet Faq-O-Matic is located at <a
href="http://www.cs.dartmouth.edu/research/ssfnet/faq/fom.cgi">http://www.cs.dartmouth.edu/research/ssfnet/faq/fom.cgi</a>.
</p>

<a name="references"></a>
<h3>References</h3>

<p>
<a name="ref1">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[1]
<font face="fixed">&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc2328.txt">RFC2328: OSPF Version 2</a><br>
</p>

<p>
<a name="ref2">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[2]
<font face="fixed">&nbsp;</font><font color="blue"><i>Routing in the Internet</i></font> by Christian Huitema<br>
</p>

<a name="about"></a>
<h3>Authors</h3>

<p align="justify">
SSF.OS.OSPF was originally authored by by Philip Kwok under the advisership of
Andy Ogielski.  Myongsu Choe implemented DML configurability, NHI addressing,
and a number of bugfixes.  BJ Premore collaborated throughout the project, and
has taken over as maintainer and developer as of version 0.1.0.  Validation
tests were originally written by Philip Kwok and have been updated and modified
by Myongsu Choe, Andy Ogielski, and BJ Premore.
</p>

<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>

</body>
</html>
